\section{Строки}
\label{sec:digging_strings}

\input{digging_into_code/strings/main_RU}

\subsection{Поиск строк в бинарном файле}

\epigraph{Actually, the best form of Unix documentation is frequently running the
\textbf{strings} command over a program’s object code. Using \textbf{strings}, you can get
a complete list of the program’s hard-coded file name, environment variables,
undocumented options, obscure error messages, and so forth.}{The Unix-Haters Handbook}

\myindex{UNIX!strings}
Стандартная утилита в UNIX \IT{strings} это самый простой способ увидеть строки в файле.
Например, это строки найденные в исполняемом файле sshd из OpenSSH 7.2:

\lstinputlisting{digging_into_code/sshd_strings.txt}

Тут опции, сообщения об ошибках, пути к файлам, импортируемые модули, функции, и еще какие-то странные строки (ключи?)
Присутствует также нечитаемый шум---иногда в x86-коде бывают целые куски состоящие из печатаемых ASCII-символов,
вплоть до ~8 символов.

Конечно, OpenSSH это опенсорсная программа.
Но изучение читаемых строк внутри некоторого неизвестного бинарного файла это зачастую самый первый шаг в анализе.
\myindex{UNIX!grep}

Также можно использовать \IT{grep}.

\myindex{Hiew}
\myindex{Sysinternals}
В Hiew есть такая же возможность (Alt-F6), также как и в Sysinternals ProcessMonitor.

\subsection{Сообщения об ошибках и отладочные сообщения}

Очень сильно помогают отладочные сообщения, если они имеются. В некотором смысле, отладочные сообщения, 
это отчет о том, что сейчас происходит в программе.
Зачастую, это \printf-подобные функции, 
которые пишут куда-нибудь в лог, а бывает так что и не пишут ничего, но вызовы остались, так как эта сборка --- не
отладочная, а \IT{release}.

\myindex{\oracle}
Если в отладочных сообщениях дампятся значения некоторых локальных или глобальных переменных, 
это тоже может помочь, как минимум, узнать их имена. 
Например, в \oracle одна из таких функций: \TT{ksdwrt()}.

Осмысленные текстовые строки вообще очень сильно могут помочь. 
Дизассемблер \IDA может сразу указать, из какой функции и из какого её места используется эта строка. 
Встречаются и смешные случаи
\footnote{\href{http://go.yurichev.com/17223}{blog.yurichev.com}}.

Сообщения об ошибках также могут помочь найти то что нужно. 
В \oracle сигнализация об ошибках проходит при помощи вызова некоторой группы функций. \\
Тут еще немного об этом: \href{http://go.yurichev.com/17224}{blog.yurichev.com}.

\myindex{Error messages}
Можно довольно быстро найти, какие функции сообщают о каких ошибках, и при каких условиях.

Это, кстати, одна из причин, почему в защите софта от копирования, 
бывает так, что сообщение об ошибке заменяется 
невнятным кодом или номером ошибки. Мало кому приятно, если взломщик быстро поймет, 
из-за чего именно срабатывает защита от копирования, просто по сообщению об ошибке.

Один из примеров шифрования сообщений об ошибке, здесь: \myref{examples_SCO}.

\subsection{Подозрительные магические строки}

Некоторые магические строки, используемые в бэкдорах выглядят очень подозрительно.
Например, в домашних роутерах TP-Link WR740 был бэкдор
\footnote{\url{http://sekurak.pl/tp-link-httptftp-backdoor/}, на русском: \url{http://m.habrahabr.ru/post/172799/}}.
Бэкдор активировался при посещении следующего URL:\\
\url{http://192.168.0.1/userRpmNatDebugRpm26525557/start_art.html}.\\
Действительно, строка \q{userRpmNatDebugRpm26525557} присутствует в прошивке.

Эту строку нельзя было нагуглить до распространения информации о бэкдоре.

Вы не найдете ничего такого ни в одном \ac{RFC}.

Вы не найдете ни одного алгоритма, который бы использовал такие странные последовательности байт.

И это не выглядит как сообщение об ошибке, или отладочное сообщение.

Так что проверить использование подобных странных строк --- это всегда хорошая идея.
\\
\myindex{base64}
Иногда такие строки кодируются при помощи 
base64\footnote{Например, бэкдор в кабельном модеме Arris: 
\url{http://www.securitylab.ru/analytics/461497.php}}.
Так что неплохая идея их всех декодировать и затем просмотреть глазами, пусть даже бегло.
\\
\myindex{Security through obscurity}

Более точно, такой метод сокрытия бэкдоров называется \q{security through obscurity} (безопасность через
запутанность).
